home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16182 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.7 KB
  1. Path: noc.netcom.net!news
  2. From: Sean Palmer <sean@delta.com>
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.os.msdos.programer,comp.os.ms-windows.programmer.misc
  4. Subject: Re: fastest code
  5. Date: Tue, 09 Apr 1996 15:28:22 -0400
  6. Organization: deltaComm Development, Inc.
  7. Message-ID: <316ABA56.3A68@delta.com>
  8. References: <316112A2.7D37@public.sta.net.cn> <31611AC9.7DE1@wight.hursley.ibm.com> <3162c21a.6084138@204.248.25.97> <31641DE2.31D4@halcyon.com> <31658942.99299605@204.248.25.97> <4k9g04$4ov@news1.mnsinc.com>
  9. NNTP-Posting-Host: landspeeder.delta.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 3.0B2 (Win95; I)
  14.  
  15. > : The original question was looking for this kind of information (even
  16. > : if the poster does not understand Big-O, which I don't know if he did
  17. > : or not).  He wants to know what compiler will best optimize the
  18. > : machine language code generated for a specific OS and computer
  19. > : architecture.
  20. > 
  21. > Optimizations have little to do with time complexities as well.  A
  22. > compiler today is not likely to change an O(n^2) algorithm into an
  23. > O(n) algorithm simply by optimizing the code, though an O(n) algorithm
  24. > might be optimized into an O(1) algorithm if you're talking about a
  25. > truly dumb programmer ;).
  26.  
  27. Being dumb aside, if the (fictitious bad) compiler, for this C++ code:
  28.  
  29. void test(int& x) {
  30.   if (!(x==0))
  31.     x=x+1;
  32.   }
  33.  
  34. generates the following x86 asm code:
  35.  
  36. test@i:
  37.   push esi
  38.   push edi
  39.   push ebp
  40.   mov ebp,esp
  41.   push eax
  42.   push ebx
  43.  
  44.   mov eax,[x]
  45.   mov ebx,[eax]
  46.   cmp ebx,0
  47.   jz @@loc2
  48.   jmp @@loc1
  49. @@loc2:
  50.   mov eax,[x]
  51.   mov ebx,[eax]
  52.   add ebx,1
  53.   mov eax,[x]
  54.   mov [x],ebx
  55. @@loc1:
  56.  
  57.   pop ebx
  58.   pop eax  
  59.   pop ebp
  60.   pop edi
  61.   pop esi
  62.   ret
  63.  
  64. while another compiler generates this code:
  65.  
  66. test@i:
  67.   mov ebx,[eax]
  68.   test ebx,ebx
  69.   jnz @@loc1
  70.   inc dword ptr [eax]
  71. @@loc1:
  72.   ret  
  73.  
  74.  
  75. which would you rather call in a 10000-iteration loop?
  76.  
  77. The difference, is that the first one would force you (if writing a 
  78. video game for instance) to code 30% of the game in assembly language 
  79. to get the necessary speed, where the second compiler would allow you to 
  80. code 90% of the game in good ol' readable, maintainable, portable C++...
  81. because writing in assembler wouldn't get you a noticeable speed gain.
  82.  
  83. Sure, a good optimizer isn't going to fix a bad algorithm. But a bad 
  84. optimizer will sure slow down a good algorithm... 
  85.  
  86. Take Borland vs. Watcom for instance. Borland has a hideous code 
  87. generator. Watcom's makes code that's often faster than what I would 
  88. write. It looks wierd, but it's fast. 
  89.  
  90. Borland won't even inline functions that contain loops or switch 
  91. statements. It even balks on complicated if statements. Watcom has no 
  92. such restriction.
  93.